1. Field of the Invention
The present invention relates to the field of microprocessors, and in particular, to systems and methods for processing exceptions.
2. Background Art
A pipelined processor is organized as a series of cascaded stages of hardware. Instruction processing is divided into a sequence of operations, and each operation is performed by resources in a corresponding pipeline stage ("pipe stage"). Independent operations from several instructions may be processed simultaneously by different pipe stages, increasing the instruction throughput of the pipeline. By including multiple execution resources in each pipe stage, the pipelined processor can execute multiple instructions per clock cycle. Instructions that step through the processor pipeline in parallel form an issue group.
One final operation performed for each issue group is a check that determines which instructions of the issue group should update the architectural state with their results. An instruction that updates the architectural state is "committed" or "retired". An instruction may not be retired if it or an instruction that precedes it in the issue group triggers a condition or event that must be addressed by the processor outside of the scheduled flow of instructions. These conditions/events include architectural faults, architectural traps, micro-architectural faults, and micro-architectural traps, and are referred to collectively as "interruptions" or "exceptions". In the following discussion, "interruptions" and "exceptions" are used interchangeably.
When such an event/condition occurs, an "exception" is raised to signal the event to the processor. For example, an architectural exception is raised when an instruction tries to access an address that is not present in memory or the processor attempts to execute an undefined opcode. For these architectural exceptions, the processor intervenes and transfers control to a handler that addresses the triggering event. For micro-architectural exceptions, the processor may only need to flush the pipeline and reexecute the affected instructions.
Exceptions originate in the resources that are used to implement a given instruction. These resources may be referred to collectively as an execution port. For example, each instruction in an issue group is associated with a different execution port. The resources of an execution port typically include logic that is specific to the type of instructions it processes, such as branch units, floating point register files, load/store units. They also include shared resources that provide services to multiple execution ports, such as caches, translation buffers, and tables. Any of these resources may generate a warning signal (an "exception") if the instruction being processed triggers an exception.
More than one instruction in an issue group may trigger an exception, and a single instruction may generate more than one exception. Accordingly, exception signals must be collected from the different processor resources, prioritized, and analyzed to determine a highest priority exception for each issue group. The processor's response depends on the nature of the highest priority exception. When an exception occurs, the processor must determine which instruction(s) in the issue group, if any, can be retired. Retirement depends on the instruction's execution order relative to the instruction(s) of the issue group that generates the exception. The first instruction in execution order that raises an exception takes priority in the exception handling process. If this instruction raises multiple exceptions, the highest priority exception is addressed first.
Conventional processors employ a centralized exception/commit unit to process exception signals and generate commit signals to the execution ports. Centralized exception/commit units provide clean logic boundaries. However, given the relatively large number of execution resources in modern processors, the exception unit must receive and process a large number of exception signals. This can lead to signal routing problems, since all the exception signals must be provided to the centralized unit, and all the commit signals must be routed from the central unit to the various execution ports. In addition, the number of execution resources makes modern processors relatively large. This can create timing problems, especially for exceptions generated in the later pipe stages. In these cases, the exception signal must be routed to the central exception/commit unit, processed, and returned before the commit stage of the pipeline is reached.
The present invention addresses these and other problems related to exception/commit processing.